To enable better utilization and time-sharing of processor cores, application threads generally relinquish a core when they have no more work to process. In some situations, the kernel scheduler reschedules these threads onto a core when they have additional work to process. For example, another application thread may produce some work, and, therefore, may provide a notification to the kernel scheduler that a blocked thread should be rescheduled onto a different core for processing the work.
One procedure for providing this type of notification would be to invoke the operating system (OS) kernel through a blocking IO system call, which would write to a pipe causing the OS kernel to reschedule a process onto some other core. It does this by invoking some scheduling code and sending instructions to the other core, which would then cause the processors of that core to start running the notified process. When the IO activity has completed, the OS kernel typically returns from the blocking system call.
Some highly tuned applications may wish to provide notification/rescheduling to another application thread without affecting its own critical path. For instance, a highly tuned packet processing application may wish to deliver the notifications to the kernel scheduler as cheaply as possible such that the packet processing pipeline is not disrupted by a costly system call. In some instances, these notification messages can be written to a special address that can cause an interrupt based on the special address. However, in these cases the writes are only accepted from trusted peripheral devices and privileged applications.